Note that the handles returned by GetStdHandle are proper file handles and not pseudo-handles. This differs from posix where the fds have fixed values. I realise that miri does want to track the difference but I worry about confusing the terminology.

Hm, some ideas on paths forwards:

• Leave it as-is, but add documentation about the terminology here
• Try to merge stdin/out into Handle::File as normal FileDescription (basically what unix does)
  • This will require some more changes to the FileDescription trait. Its read and write methods are a bit tailored towards unix flavor currently, you may notice I have some hacky code in here to work around that. I'd like to fix it eventually anyways, but it adds more friction to MVP
• Make Handle::File hold an enum like enum FileHandle { Stdin, Stdout, File(i32) }

Its read and write methods are a bit tailored towards unix flavor currently, you may notice I have some hacky code in here to work around that. I'd like to fix it eventually anyways, but it adds more friction to MVP

Is it even worth using the same trait for Unix and Windows? The trait is indeed very tailored towards Unix, deliberately so. Knowing nothing about the Windows APIs, I expected they would need their own trait anyway.

I haven't looked yet at those hacks. Can you write a high-level summary of the pros and cons of using the same vs a different trait?

So, the main pro of reusing the trait at all is because we need a common base trait so long as we don't intend to have two different 'open file maps', one for Windows-like systems and one for Unix-like systems. And most of the FdMap code works well for this purpose - map of numbers to open files is actually a pretty good abstraction for both platforms. The read/write/seek parts of the trait aren't very file-system dependent already, as they're closer to abstractions over the File interface than the syscalls.

To use an entirely different trait, we'd have to somehow support two different dyn Trait in the file code. They also actually would be nearly identical - I think I can remove the main hack I was talking about, looking at it again with fresh eyes.

I expected we'd have two different open file maps, yeah.

But if there's stuff that can be usefully shared between Windows and Unix, even better! I just want to make sure we can keep evolving the Unix side without being held back by constraints or lack of knowledge about what happens on the Windows side.